Programmable logic devices (“PLDs”) are a well-known type of integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (“FPGA”), typically includes an array of programmable tiles. These programmable tiles can include, for example, input/output blocks (“IOBs”), configurable logic blocks (“CLBs”), dedicated random access memory blocks (“BRAMs”), multipliers, digital signal processing blocks (“DSPs”), processors, clock managers, delay lock loops (“DLLs”), and so forth. Notably, as used herein, “include” and “including” mean including without limitation.
One such FPGA is the Xilinx Virtex® FPGA available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124. Another type of PLD is the Complex Programmable Logic Device (“CPLD”). A CPLD includes two or more “function blocks” connected together and to input/output (“I/O”) resources by an interconnect switch matrix. Each function block of the CPLD includes a two-level AND/OR structure similar to those used in Programmable Logic Arrays (“PLAs”) and Programmable Array Logic (“PAL”) devices. Other PLDs are programmed by applying a processing layer, such as a metal layer, that programmably interconnects the various elements on the device. These PLDs are known as mask programmable devices. PLDs can also be implemented in other ways, for example, using fuse or antifuse technology. The terms “PLD” and “programmable logic device” include but are not limited to these exemplary devices, as well as encompassing devices that are only partially programmable.
For purposes of clarity, FPGAs are described below though other types of PLDs may be used. FPGAs may include one or more embedded microprocessors. For example, a microprocessor may be located in an area reserved for it, generally referred to as a “processor block.”
FPGAs are suited for implementing circuits to process various types of content, such as video data, audio data, image data, or a combination of one or more thereof, namely multimedia data. With these various forms of data, there are various forms of encoding that may be used. Accordingly, a decoder is configured to support the type of encoding used, which generally limits the type of encoding to a standard form. For example, with respect to video data, use of Motion Picture Experts Group (“MPEG”) types of encoding, and thus decoding, is ubiquitous as a commonly used platform for encoding and decoding of video data.
Heretofore, a designer would not depart from a commonly used standard form of encoding data, as encoders and decoders, including coder/decoders (“CODECs”), would have to be manufactured to be compatible with such deviation. Conventionally, however, hardware has been manufactured to operate using known standard types of encoding and decoding. This is because data or content is conventionally encoded to a known standard, and manufacturing hardware to support known standards allows such content to be used on various hardware platforms supporting such known standards.
In other instances for example, CODECs are implemented as software; however, such software CODECs generally are slower than their hardware counterparts. Special purpose CODECs, whether in software or hardware or a combination thereof, have been manufactured. But, in these instances, content created using such special purpose CODECs is generally only usable with such special purpose platforms.
Continuing the example of video content, there are many areas where content may be enhanced beyond that available using a standard form of encoding. For example, there are many factors in producing video content, including the type of motion compensation, the type of motion estimation, the parameters used for transform from frequency to time domain, the parameters used for inverse transform from time to frequency domain, the resolution, the various types of filtering, and so on.
The latest trend in video coding is to provide various forms of scalability, sometimes all embodied within the same video bitstream. Typically, this data is provided in the form of a “base layer,” as well as one or more “enhancement layers.” A CODEC system would thus need to be capable of creating a valid video output using just the base layer or the base layer and any combination of the enhancement layers. Exemplary types of scalability provided in the enhancement layers include: temporal scalability (e.g., frame rate), quality scalability (e.g., often measured by peak signal-to-noise ratio), and resolution scalability (e.g., frame size). An example of this type of CODEC is embodied in the scalable video coding (“SVC”) development work currently ongoing. SVC is an extension to the MPEG-4 Advanced Video Coding (AVC) standard (also known as MPEG-4, Part 10) jointly developed by the International Organization for Standardization (ISO) and International Telecommunication Union (ITU-T). The MPEG-4 AVC standard is published as ITU-T H.264 and ISO/IEC 14496-10.
The proposed SVC CODEC provides all three of the aforementioned types of scalability (e.g., temporal, quality, and resolution) in labeled packets within the same bitstream. Either a smart network can be used to decide which types of packets to send to a particular end-user, or the end-user can receive the entire bitstream and only decode the packets for which he or she has the capability and authorization to decode. However, even with an SVC CODEC, an upper limit is in place, as only MPEG-approved enhancement layers are supported.
Accordingly, it would be desirable and useful to provide means that allows for use of standards-based encoding and decoding, but also allows for content to be encoded and decoded using a customized solution that is less platform dependent.